Wombat A Portable User-Mode Linux for Embedded Systems

Embedded systems are the biggest potential market for Linux, much bigger (in terms of number as well as total value) than either the desktop or the server market. While Linux is making excellent inroads into (high-end) embedded systems, a number of challenges particular to embedded systems threaten to limit its impact. These include the requirements for hard real-time capability, extreme robustness, and, in particular, a minimal trusted computing base. The viral nature of the GPL is also frequently causing problems. We argue that a portable user-mode Linux which runs on a truly minimal kernel is the answer, and will open up application domains which would otherwise be hard to penetrate. We present such a system, called Wombat, which is a port of Linux kernel to the L4 microkernel. Wombat is readily portable between architectures (presently runs on x86, ARM and MIPS), and initial performance evaluations look promising. 1 Embedded Systems: The Next Frontier Embedded systems are characterised as devices which are not primarily computers but contain one or more processors, operating “behind the scenes”, in order to provide part of the device’s functionality. The embedded market is huge — well over 99% of all processors are embedded — and growing strongly (while the PC and server markets are comparatively flat). Presently, the vast majority of embedded systems are based on rather primitive processors, 8or 16bit micro-controllers without memory protection, performing relatively simple control operations. Such devices tend to have little or no operating system (OS), their software comprises essentially a control loop which executes task according to a fixed schedule, and some minimal “kernel’,’ consisting of some device drivers and simple libraries. However, there is a strong trend from those “classical” embedded systems towards more powerful platforms, 32-bit (sometimes even 64-bit) general-purpose processors which provide memory protection via a memory-management unit (MMU). The reasons for this development include the market demand for more sophisticated embedded systems with a lot of complex functionality. A typical example are personal communication and entertainment devices, where there is an increasing convergence of what used to be dissimilar devices, into a single system offering a wide variety of functions. Such devices have requirements that are quite different from those of classical (closed) embedded systems: high demand on processing capability, and a much more open architecture, which features internet connectivity, field upgradability via remote access, standardised and well-known application programming interface (API) and the ability to process downloaded data and even execute downloaded code. These are requirements that are well supported by contemporary desktop and server operating systems, and it is therefore not surprising that there is a strong trend towards an increasing use of standard operating systems, such as Linux, in embedded systems. In fact, surveys show that Linux is the leading OS for new embedded systems work, with (various versions of) Windows taking second place [Lin04]. 2 2 EMBEDDED SYSTEMS CHALLENGES While we suspect that such surveys are strongly biased towards 32-bit systems and therefore somewhat misleading, there is little doubt that the tendency towards “standard” OSes in embedded systems is real, and presents the strongest growth potential for Linux. The main reasons that are typically given for the popularity of Linux in embedded systems are sourcecode availability and the royalty-free status. Surveys show that many embedded systems developers are willing to pay for development environments, training and other support, but are unwilling to share the income from their products (in the form of per-unit royalties) [EDC03]. 2 Embedded Systems Challenges While modern embedded systems have requirements that are well supported by Linux, they provide a number of other challenges, which make Linux a less-than-ideal choice. These include: hard real-time: Embedded systems are mostly real-time systems, meaning that they have to respond to external events in a timely fashion. In many cases (eg. multi-media systems) this real-time requirement is “soft”, meaning that such systems can tolerate missing a deadline occasionally. Other systems have “hard” real-time requirements: missing a deadline is considered a complete system failure, and may result in mission failure or even death. In spite of very significant progress in Linux’s real-time responsiveness, normal Linux is not suitable for hard real-time systems, and there are signs that the situation has recently worsened [SM04]. Special real-time versions, such as RTLinux [FSM] and RTAI [RTA] address the problem by adding a real-time layer below the kernel proper, in order to have full control over interrupt handling. This leads to an architecture which is, in principle, capable of meeting real-time requirements, although at a cost of running the real-time components in the kernel (with corresponding loss of protection). However, the resulting system is still too complex to be fully analysed with respect to its real-time performance, with a resulting uncertainty about its ability to really meet the real-time goals. In fact, it has been shown that a heavily-loaded RTLinux system fails to honour its real-time guarantees [MHH02]. Ideally, the system’s real-time performance should be established either by mathematical proof, or by a complete empirical execution-time analysis of all its possible execution paths. This is only practical if the kernel and other real-time components are very small. highly robust: Embedded systems are often employed in life-critical or mission-critical scenarios. While the reliability of Linux on desktops and servers is very high, this typically applies to systems which are at least close to widely-deployed configurations. Massive changes to system configuration, as it is typically necessary for an embedded system, will inherently reduce stability and require a significant maturation process. In the meantime, the critical parts of the system should not be affected by other components which may only be required for supporting a user interface or some non-critical entertainment function. Furthermore, the critical part of the system must be protected from attacks by malicious programs which the user downloaded from the internet. A related issue is that of upgrading the system without downtime. While it is possible, in theory, to upgrade Linux kernel modules without rebooting the whole system, in practice this is very limited, as many modules are tied closely to a specific kernel version, making it impossible to load a newer version of the model into an old kernel. Other components of the kernel are impossible to upgrade without a reboot; small trusted computing base: A system’s trusted computing base (TCB) is the set of components of a system which must be assumed to operate correctly in order to ascertain the reliability of any part of the system, and the confidentiality and integrity of its data. Note that this does not necessarily mean that all components of the TCB are actually trustworthy, but clearly the system can only be trusted to perform its core functionality if the TCB can be trusted too.